Execution of user interface (ui) tasks having foreground (fg) and background (bg) priorities

ABSTRACT

A method includes, in a user device configured to execute User Interface (UI) tasks that process one or more UI displays presented to a user, assigning to each UI task among the UI tasks (i) a priority selected from at least a Foreground (FG) priority and a Background (BG) priority, and (ii) an association with a UI display being processed by the UI task. The UI tasks are scheduled for execution in accordance with a schedule that (i) gives precedence to the UI tasks having the FG priority over the UI tasks having the BG priority, and (ii) for any UI display, retains in-order execution of the UI tasks associated with the UI display. The UI tasks are executed in accordance with the schedule.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of PCT application PCT/IB2020/057046,filed Jul. 26, 2020, which claims the benefit of U.S. Provisional PatentApplication 62/880,092, filed Jul. 30, 2019, and U.S. Provisional PatentApplication 62/880,674, filed Jul. 31, 2019. The disclosures of theserelated applications are incorporated herein by reference.

FIELD OF THE INVENTION

The present invention relates generally to communication systems, andparticularly to pre-rendering of content in user devices.

BACKGROUND OF THE INVENTION

In applications (“apps”) that run on user devices such as smartphones,one of the major factors affecting user experience is the latency of theUser Interface (UI). Various techniques have been proposed for reducinglatency and providing a more responsive UI. Some techniques involveprefetching of content. Other techniques involve background preloadingof apps. Yet other techniques involve pre-rendering of an app's UI.Techniques of this sort are described, for example, in PCT InternationalPublication WO 2018/055506, entitled “An Optimized CDN for the WirelessLast Mile,” which is incorporated herein by reference.

SUMMARY OF THE INVENTION

An embodiment of the present invention that is described herein providesa method including, in a user device that is configured to communicateover a network, preloading an application in a background mode in whichcontent presented by the application is hidden from a user of the userdevice. At least part of the content presented by the application ispre-rendered in an off-line pre-render mode in which fetching of contentover the network to the user device is not permitted. In response to anaction by the user that requests to access the application, a switch ismade to presenting at least the pre-rendered content to the user in aforeground mode.

In some embodiments, pre-rendering in the off-line pre-render modeincludes declining network-related requests from the application.Declining the network-related requests may include responding to thenetwork-related requests from the application with a response indicatingthe network is unavailable.

In an embodiment, pre-rendering in the off-line pre-render mode includesrendering at least part of the content from a local cache in the userdevice. In another embodiment, pre-rendering in the off-line pre-rendermode includes notifying the application that pre-rendering is performedin accordance with the off-line pre-render mode. In yet anotherembodiment, pre-rendering in the off-line pre-render mode includespre-rendering a placeholder item in place of an actual content item thatrequires fetching over the network.

In still another embodiment, pre-rendering in the off-line pre-rendermode includes penalizing the application for requesting to fetch acontent item over the network. In an example embodiment, pre-renderingin the off-line pre-render mode includes receiving in the application,via an Application Programming Interface (API), an indication thatpre-rendering is performed in accordance with the off-line pre-rendermode, and in response running program code that pre-renders the contentin accordance with the off-line pre-render mode.

In a disclosed embodiment, switching to the foreground mode includesrefreshing at least some of the content over the network. In anotherembodiment, pre-rendering in the off-line pre-render mode is performedin response to an acknowledgement from the application, indicating thatthe application supports the off-line pre-render mode.

In some embodiments, preloading the application includes choosing, basedon a criterion, whether to pre-render the content in accordance with theoff-line pre-render mode, or in accordance with an on-line pre-rendermode in which it is permitted to fetch content over the network to theuser device. In an embodiment, pre-rendering in the on-line pre-rendermode includes receiving in the application, via an ApplicationProgramming Interface (API), an indication that pre-rendering isperformed in accordance with the on-line pre-render mode, and inresponse running program code that pre-renders the content in accordancewith the on-line pre-render mode. In another embodiment, choosing theon-line pre-render mode is performed in response to an acknowledgementfrom the application, indicating that the application supports theon-line pre-render mode. In a disclosed embodiment, the criteriondepends on at least one factor selected from (i) a usage pattern of theapplication, (ii) a condition of the user device, and (iii) a conditionof the network.

There is additionally provided, in accordance with an embodiment of thepresent invention, a method including issuing, by an application runningin a user device, a request to fetch over the network content thatincludes multiple content items. The request is received by a softwareagent running in the user device and, in response to the request, achain of fetch operations is executed for fetching the requestedcontent. Each of the fetch operations in the chain includes (i)receiving from the application an identification of one or moreadditional content items identified by the application within a contentitem fetched in a preceding fetch operation in the chain, (ii)evaluating a criterion, and (iii) deciding, depending on the criterion,whether or not to fetch the one or more additional content items.

In some embodiments, the method includes pre-rendering one or more ofthe content items in a background mode. In some embodiments, issuing therequest includes prefetching the content, not in response to a useraccessing the content.

There is also provided, in accordance with an embodiment of the presentinvention, a method including, in a user device, which is configured toexecute User Interface (UI) tasks that process one or more UI displayspresented to a user, assigning to each UI task among the UI tasks (i) apriority selected from at least a Foreground (FG) priority and aBackground (BG) priority, and (ii) an association with a UI displaybeing processed by the UI task. The UI tasks are scheduled for executionin accordance with a schedule that (i) gives precedence to the UI taskshaving the FG priority over the UI tasks having the BG priority, and(ii) for any UI display, retains in-order execution of the UI tasksassociated with the UI display. The UI tasks are executed in accordancewith the schedule.

In some embodiments, one or more of the UI tasks having the BG priorityinclude pre-rendering tasks. In an embodiment, at a given time, the UItasks include both (i) one or more UI tasks having the BG priority, and(ii) one or more UI tasks having the FG priority that relate to useractions. In a disclosed embodiment, executing the UI tasks is performedby a single UI thread per user application.

In some embodiments, assigning the priority includes, in response toaddition of a new UI task having the FG priority, identifying one ormore UI tasks that (i) are associated with a same UI display as the newUI task and (ii) have the BG priority, and promoting the identified UItasks to the FG priority. In an example embodiment, scheduling the UItasks includes scheduling the promoted UI tasks to be executed beforethe new UI task. In another embodiment, scheduling the UI tasks includesretaining an original order of execution among the promoted UI tasks. Inyet another embodiment, scheduling the UI tasks includes permittingout-of-order execution of UI tasks associated with different UIdisplays.

There is further provided, in accordance with an embodiment of thepresent invention, a user device including an interface forcommunicating over a network, and a processor. The processor isconfigured to preload an application in a background mode in whichcontent presented by the application is hidden from a user of the userdevice, to pre-render at least part of the content presented by theapplication in an off-line pre-render mode in which fetching of contentover the network to the user device is not permitted, and, in responseto an action by the user that requests to access the application, toswitch to presenting at least the pre-rendered content to the user in aforeground mode.

There is also provided, in accordance with an embodiment of the presentinvention, a user device including an interface for communicating over anetwork, and a processor. The processor is configured to issue, by anapplication running on the processor, a request to fetch over thenetwork content that includes multiple content items, to receive therequest by a software agent running on the processor and, in response tothe request, execute a chain of fetch operations for fetching therequested content, wherein each of the fetch operations in the chaincomprises (i) receiving from the application an identification of one ormore additional content items identified by the application within acontent item fetched in a preceding fetch operation in the chain, (ii)evaluating a criterion, and (iii) deciding, depending on the criterion,whether or not to fetch the one or more additional content items.

There is additionally provided, in accordance with an embodiment of thepresent invention, a user device including an interface forcommunicating over a network, and a processor. The processor isconfigured to assign, to each User Interface (UI) task from amongmultiple UI tasks that process one or more UI displays presented to auser, (i) a priority selected from at least a Foreground (FG) priorityand a Background (BG) priority, and (ii) an association with a UIdisplay being processed by the UI task, to schedule the UI tasks forexecution in accordance with a schedule that (i) gives precedence to theUI tasks having the FG priority over the UI tasks having the BGpriority, and (ii) for any UI display, retains in-order execution of theUI tasks associated with the UI display, and to execute the UI tasks inaccordance with the schedule.

The present invention will be more fully understood from the followingdetailed description of the embodiments thereof, taken together with thedrawings in which:

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram that schematically illustrates a communicationsystem that employs Preloading, Pre-rendering and Prefetching (PPP), inaccordance with an embodiment of the present invention;

FIG. 2 is a flow chart that schematically illustrates a method forcontent pre-rendering using an off-line pre-render mode, in accordancewith an embodiment of the present invention;

FIG. 3 is a flow chart that schematically illustrates a method forcontent prefetching using a prefetch parse chain, in accordance with anembodiment of the present invention; and

FIG. 4 is a flow chart that schematically illustrates a method forhandling background and foreground User Interface (UI) tasks using asingle UI thread, in accordance with an embodiment of the presentinvention.

DETAILED DESCRIPTION OF EMBODIMENTS Overview

Embodiments of the present invention that are described herein provideimproved methods and systems for Preloading, Pre-rendering andPrefetching (PPP) in user devices. In the present context, the term“preloading” refers to the process of loading, launching and at leastpartially running an app in a background mode, not in response to (andtypically before) invocation of the app by the user. The term“pre-rendering” refers to the process of constructing a UI display of anapp in the background mode. The term “UI display” in this context refersto a logical UI element—A view or a window. In the Android OS, forexample, UI displays are referred to as Views or Activities.

Note that pre-rendering may involve UI tasks that modify the UI display,and/or UI tasks that do not directly modify the UI display but areprerequisite to such modification or are synced to modification of theUI display in the background. Thus, for example, initialization orpreparatory tasks that are performed when preloading an app andpreparing to initialize or modify a UI display of the app are alsoregarded herein as pre-rendering tasks.

The term “prefetching” refers to the process of fetching content over anetwork, from a content source to a local cache memory of the userdevice, not in response to an explicit request or access by the user.

In some embodiments, as part of preloading an app, the user devicepre-renders a UI display of the app in the background. The UI displaybeing pre-rendered may comprise various content items, e.g., text,images, graphics, videos and the like. In some embodiments, the userdevice pre-renders at least some of the content of the UI display usingan “off-line pre-render mode” in which fetching of content over thenetwork to the user device is not permitted.

The off-line pre-render mode can be implemented in various ways. Forexample, instead of fetching content items over the network, the userdevice may pre-render locally-cached versions of the content itemsregardless of whether they are fresh or stale or up to a predefinedextent of staleness. As another example, the user device may pre-renderempty “placeholder” content items having similar dimensions as theactual content items. When the user requests to access the app inquestion, the user device moves the pre-rendered UI display to theforeground, so as to present the pre-rendered content to the user. Atthis stage, the user device may refresh missing or stale content itemsover the network.

Some disclosed techniques assume that the app supports the off-linepre-rendering mode. Other disclosed techniques do not make thisassumption. For apps that do not support the off-line pre-renderingmode, various ways of enforcing off-line pre-rendering, i.e., preventingapps' network requests from reaching the network, are described.

Additionally or alternatively to the off-line pre-render mode, the userdevice may support an on-line pre-render mode in which fetching ofcontent over the network is permitted. As opposed to on-linepre-rendering, which does not restrict network access, the off-linepre-rendering mode balances user experience with cost. In other words,on-line pre-rendering minimizes the latency of presenting the user afully operational and relatively fresh UI display, but on the other handincurs data costs, along with related power/battery drain costs. Theoff-line pre-rendering mode reduces the data cost for the user deviceand/or the app server, but may initially present to the user anincomplete or relatively stale UI display for a short period of time. Assuch, the off-line pre-rendering mode enables a flexible trade-offbetween latency and cost. Embodiments that combine (e.g., choosebetween) off-line and on-line pre-rendering are also described.

Other disclosed embodiments relate to handling of “parse chains.” Inpractice, a content item often links to one or more additional(“nested”) content items, each of which may link to one or more yetadditional content items, and so on. An app that receives such a contentitem typically parses it, discovers one or more additional content itemswithin the parsed content item, requests to fetch the discovered contentitems, and so on. In some embodiments, the user device runs an agentthat handles parse chains.

In particular, the agent decides, for each additional content item beingidentified as part of a parse chain, whether to fetch the content itemover the network or not. The agent may use various criteria for decidingwhether or not to fetch an additional content item, and in particular todecide whether to terminate the parse chain entirely. The disclosedparse-chain handling techniques are useful in various use-cases.Examples relating to pre-rendering and to general prefetching aredescribed. In pre-rendering, the selective fetching of content items ina parse chain is used as a “hybrid pre-rendering” mode. Such a mode isuseful, for example, for reducing costs such as integration effort, datausage and battery drain.

Yet other disclosed embodiments relate to correct prioritization andscheduling of foreground and background UI tasks that are associatedwith the same UI display. In some operating systems, for example iOS andAndroid, such UI tasks are typically handled by a single UI thread perapp in the user device. In particular, disclosed techniques address thecase of a user performing some action in the foreground with respect toa UI display of an app, while another UI display of the same app isbeing pre-rendered in the background. Such cases are challenging forseveral reasons. For example, unless handled properly, pre-rendering UItasks might cause the app to appear non-responsive to the user'sactions. As another example, since UI tasks of a given UI display shouldbe handled in-order, it would be incorrect to execute theuser-action-related UI tasks before any pending pre-rendering-related UItasks. As noted above, pre-rendering UI tasks may comprise tasks thatmodify the UI display directly, and/or initialization or prerequisitetasks that do not directly modify the UI display.

In some embodiments, an agent running in the user device overcomes suchchallenges by proper prioritization and scheduling of the UI tasks. Asexplained in detail herein, the agent assigns each UI task a priorityselected from at least a Foreground (FG) priority and a Background (BG)priority. In addition, the agent associates each UI task with the UIdisplay (also referred to as “scenario”) processed by this UI task. Theagent schedules the UI tasks for execution in accordance with a schedulethat (i) gives precedence to the UI tasks having the FG priority overthe UI tasks having the BG priority, and (ii) for any UI display,retains in-order execution of the UI tasks associated with the UIdisplay. The UI tasks are then executed in accordance with the schedule.

In some embodiments, in order to retain in-order execution of the UItasks of a given UI display, the agent applies a “promotion” mechanismthat promotes selected UI tasks from the BG priority to the FG priority.In response to creation of a new UI task having the FG priority (e.g., aUI task derived from a user action), the agent identifies all UI tasksthat are both (i) associated with the same UI display as the new UI taskand (ii) assigned the BG priority, and promotes the identified UI tasksto the FG priority. The agent schedules the promoted UI tasks to beexecuted before the new UI task, and also retains the original order ofexecution among the promoted UI tasks.

System Description

FIG. 1 is a block diagram that schematically illustrates a communicationsystem 20 that employs Preloading, Pre-rendering and Prefetching (PPP),in accordance with an embodiment of the present invention.

System 20 comprises a user device 24, which runs one or more userapplications (“apps”) 26. Device 24 may comprise any suitable wirelessor wireline device, such as, for example, a cellular phone orsmartphone, a wireless-enabled laptop or tablet computer, a desktoppersonal computer, a video gaming console, a smart TV, a wearabledevice, an automotive user device, or any other suitable type of userdevice that is capable of communicating over a network and presentingcontent to a user. The figure shows a single user device 24 for the sakeof clarity. Real-life systems typically comprise a large number of userdevices of various kinds.

In the present context, the terms “user application,” “application” and“app” are used interchangeably, and refer to any suitable computerprogram that runs on the user device and may be invoked (activated) bythe user. Some apps 26 may be dedicated, special-purpose applicationssuch as game apps. Other apps 26 may be general-purpose applicationssuch as Web browsers.

In some embodiments, although not necessarily, apps 26 are provided byand/or communicate with one or more network-side servers, e.g., portals28, over a network 32. Network 32 may comprise, for example a Wide AreaNetwork (WAN) such as the Internet, a Local Area Network (LAN), awireless network such as a cellular network or Wireless LAN (WLAN), orany other suitable network or combination of networks.

In the present example, user device 24 comprises a processor 44 thatcarries out the various processing tasks of the user device. Among othertasks, processor 44 runs apps 26, and also runs a software componentreferred to as a Preload/Pre-render/Prefetch (PPP) agent 48, whichhandles preloading of apps, content pre-rendering and/or contentprefetching. Apps 26 and PPP agent 48 are drawn schematically insideprocessor 44, to indicate that they comprise software running on theprocessor.

In addition, user device 24 comprises a Non-Volatile Memory (NVM) 54,e.g., a Flash memory. NVM 54 may serve, inter alia, for storing a cachememory 52 for caching content associated with apps. In some embodimentsthe user device uses a single cache 52. In other embodiments, alsodepicted schematically in the figure, a separate cache memory 52 may bedefined per app. Hybrid implementations, in which part of cache 52 iscentralized and some is app-specific, are also possible. For clarity,the description that follows will refer simply to “cache 52”, meaningany suitable cache configuration.

User device 24 further comprises a display screen 56 for presentingvisual content to the user, and a suitable network interface (not shownin the figure) for connecting to network 32. This network interface maybe wired (e.g., an Ethernet Network Interface Controller—NIC) orwireless (e.g., a cellular modem or a Wi-Fi modem). Typically, userdevice 24 further comprises some internal memory, e.g., Random AccessMemory (RAM)—not shown in the figure—that is used for storing relevantcode and/or data.

In the example embodiment of FIG. 1, although not necessarily, system 20further comprises a PPP subsystem 60 that performs preloading,pre-rendering and/or prefetching tasks on the network side. Subsystem 60comprises a network interface 64 for communicating over network 32, anda processor 68 that carries out the various processing tasks of the PPPsubsystem. In the present example, processor 68 runs a PPP control unit72 that carries out network-side PPP tasks. Network-side PPP tasks maycomprise, for example, deciding which apps to preload and when, orchoosing whether and which in-app content to preload, deciding how muchof an app component to preload (e.g., only executing some initialexecutable code, or pre-rendering of the app's user interface), to namejust a few examples. In an embodiment, PPP subsystem 60 may beimplemented as a cloud-based application.

In the embodiments described herein, for the sake of clarity, the PPPtasks are described as being carried out by processor 44 of user device24. Generally, however, PPP tasks may be carried out by processor 44 ofdevice 24, by processor 68 of subsystem 60, or both. Thus, any referenceto “processor” below may refer, in various embodiments, to processor 44,processor 68, or both.

Preloading an app 26 may involve preloading any app element such asexecutable code associated with the app, e.g., launch code, app feed,app landing page, various UI elements associated with the app, contentassociated with the app, app data associated with the app, and/or codeor content that is reachable using the app by user actions such asclicks (“in-app content”). Pre-rendering of content is typicallyperformed in an app that has been preloaded and is currently running inthe background. Pre-rendering may involve background processing of anysuitable kind of UI display, or a portion thereof. In Androidterminology, for example, pre-rendering may comprise backgroundprocessing of one or more Android Activities. In the background mode, UIelements associated with the app are not presented to the user ondisplay screen 56, i.e., are hidden from the user. When the user invokesa previously-preloaded app, the user device switches to run the app in aforeground mode that is visible to the user. (The terms “backgroundmode” and “foreground mode” are referred to herein simply as“background” and “foreground,” for brevity.)

The configurations of system 20 and its various elements shown in FIG. 1are example configurations, which are chosen purely for the sake ofconceptual clarity. In alternative embodiments, any other suitableconfigurations can be used. For example, in some embodiments the PPPtasks may be implemented entirely in processor 44 of user device 24, inwhich case subsystem 60 may be eliminated altogether.

PPP agent 48 may be implemented in a software module running onprocessor 44, in an application running on processor 44, in a SoftwareDevelopment Kit (SDK) embedded in an application running on processor44, as part of the Operating System (OS) running on processor 44(possibly added to the OS by the user-device vendor or other party), ina proxy server running on processor 44, using a combination of two ormore of the above, or in any other suitable manner. In most of thedescription that follows, PPP agent 48 is assumed to be part of the OSof user device 24.

Although the embodiments described herein refer mainly to human users,the term “user” refers to machine users, as well. Machine users maycomprise, for example, various host systems that use wirelesscommunication, such as in various Internet-of-Things (IoT) applications.

The different elements of system 20 may be implemented using suitablesoftware, using suitable hardware, e.g., using one or moreApplication-Specific Integrated Circuits (ASICs) or Field-ProgrammableGate Arrays (FPGAs), or using a combination of hardware and softwareelements. Cache 52 may be implemented using one or more memory orstorage devices of any suitable type. In some embodiments, PPP agent 48and/or subsystem 60 may be implemented using one or more general-purposeprocessors, which are programmed in software to carry out the functionsdescribed herein. The software may be downloaded to the processors inelectronic form, over a network, for example, or it may, alternativelyor additionally, be provided and/or stored on non-transitory tangiblemedia, such as magnetic, optical, or electronic memory.

Content Pre-Rendering Using Off-Line Pre-Render Mode

A UI display of an app 26 may comprise various content items, such astext, images, videos, graphics and/or other visual elements, which arelaid-out visually in accordance with a specified layout. Rendering of aUI display typically calls for fetching the content items over thenetwork. When pre-rendering a UI display in the background, however, itis possible, and sometimes beneficial, to limit the extent of networkaccess, e.g., in order to reduce power consumption, cost and/or cellulardata usage.

In some embodiments, user device 24 supports an “off-line pre-render”mode that performs pre-rendering but without permitting fetching ofcontent over network 32 to the user device. The off-line pre-render modeis also referred to herein as “off-line mode” for brevity. In someembodiments, the app whose content is being pre-rendered, and/or the OSof the user device, is required to support the off-line pre-render mode.In other embodiments, no such support is assumed.

In various embodiments, the techniques described herein may be performedby PPP agent 48, by the OS of user device 24 that runs on processor 44,and/or by apps 26. Any suitable partitioning (“division of labor”)between the PPP agent, the OS and the apps can be used. In someembodiments, the actual pre-rendering and rendering of content isperformed by the apps. The PPP agent is configured to trigger the apps,e.g., to notify an app that off-line pre-rendering is being used. ThePPP agent is implemented as a component of the OS, and both the PPPagent and the apps are orchestrated by the OS. This partitioning,however, is chosen purely by way of example. For clarity, some of thedescription that follows refers simply to processor 44 as carrying outthe disclosed techniques.

The description that follows refers to a single app 26 that has beenpreloaded and whose content is being pre-rendered. This choice is madepurely for the sake of clarity. Generally, the off-line pre-render modecan be applied to any app in user device 24, to all apps, to a selectedsubset of one or more apps, or otherwise.

For apps that already have some existing off-line features, such as theability to launch and render content regardless of network availability,the use of off-line pre-rendering allows leveraging these existingfeatures to integrate pre-rendering functions more easily. In such apps,much of the value of on-line pre-rendering (having no restrictions onnetwork access) can be retained at a considerably lower cost. For appsthat do not already have off-line user experience, the end result ofhaving a good off-line user experience provides an added incentive forintegration of pre-rendering.

In some embodiments, before the off-line pre-render mode is enabled fora given app 26, the app is required to declare to agent 48, e.g., via asuitable Application Programming Interface (API), that it supports theoff-line pre-render mode. Supporting off-line pre-rendering isbeneficial to apps, for example since it allows preloading to bescheduled more often (in comparison with on-line pre-render in whichnetwork requests are allowed) and regardless of network conditions.

In some embodiments, agent 48 intercepts requests from the app to fetchcontent over the network, and declines the requests if the app is beingpre-rendered in the off-line mode. For example, agent 48 may respond tosuch requests with a response indicating that the network isunavailable, e.g., a “not connected” response. Alternatively, agent 48may use any other suitable technique for blocking content requests fromaccessing the network.

In some embodiments, in the off-line mode, the app may pre-rendercontent items that are cached locally in cache 52 instead of fetchingthem over the network, provided that cache 52 indeed contains copies ofthe content items. In some embodiments, in the off-line mode the apppre-renders cached content items even if they are known to be stale,i.e., not fresh. This is contrast to on-line pre-rendering, in which theapp will typically fetch requested content over the network if thecached content is not fresh. In an embodiment, in the off-line mode theapp will not pre-render a cached content item if it is staler than apredefined extent, e.g., older than a predefined age.

In some embodiments, in the off-line mode, the app will pre-render a“placeholder” content item instead of the actual content item that isspecified for display in the UI display. This technique may be used, forexample, if the app requests a content item that is not availablelocally (or is staler than a predefined extent) in cache 52. Theplaceholder content item is typically an empty content item that has asimilar layout (e.g., similar dimensions) to the actual content item.Subsequently, e.g., when the user accesses the app, the app may fetchand insert the actual content item seamlessly in-place into thepre-rendered UI display.

In some embodiments, agent 48 notifies the app that its UI display isbeing pre-rendered in accordance with the off-line mode, and thereforenetwork requests are expected to fail or are not expected.Alternatively, the app may query agent 48, e.g., via a suitable API,whether a UI display of the app is being pre-rendered and using whichmode.

In some embodiments, when using such an API, the app performs bothoff-line pre-rendering and on-line pre-rendering (and possibly alsonormal rendering in the foreground) using the same launch code, but theexecution of this launch code differs between the different modes.

In an example embodiment, when operating in the off-line pre-renderingmode the app's launch code loads and pre-renders only the parts of theUI display that do not require any network resources. As a result,during pre-rendering, the app starts running in the background but stopsits progress at a point before it requires network access. The app maynot be fully operational in this state, and may require more processingto become usable. Processing is resumed once the user accesses the app.This technique considerably reduces the latency from the time the useraccesses the app to the point the UI display is fully presented andoperational, and at the same time does not require network access whilein the background.

In some embodiments, PPP agent 48 penalizes (“punishes”) an app 26 thatinitiates network requests while in the off-line pre-render mode.Penalizing an app may comprise, for example, disallowing or reducing therate of subsequent off-line pre-rendering, since the app's networkrequests indicate that the app behaves improperly in the off-line mode.

FIG. 2 is a flow chart that schematically illustrates a method forcontent pre-rendering using the off-line pre-render mode, in accordancewith an embodiment of the present invention. It is noted that the flowof FIG. 2 is depicted purely by way of example, in order to demonstratecertain features relating to off-line pre-rendering. In alternativeembodiments, the off-line pre-render mode can be implemented andutilized in any other suitable way.

The method of FIG. 2 begins with PPP agent 48 notifying an app 26 thatits UI display is to be pre-rendered using the off-line pre-renderingmode, at a notification step 80. At a preloading/pre-rendering step 84,the OS loads the app launch code and runs the app in a background mode.Since the app was notified of the off-line pre-rendering mode, the apppre-renders its UI display using locally-cached content only.

At any stage of the preloading and pre-rendering process, the user mayaccess the app. In such a case, PPP agent switches to run the app in theforeground so that the UI display is presented to the user on displayscreen 56, at a foreground switching step 88. At this stage, the app'sUI display is typically incomplete, since it comprises only elementsthat were obtainable off-line. The app then refreshes any missing orstale content in the UI display over network 32, at a refreshing step92. The refreshing operation can be performed entirely by the app or itcan be assisted by agent 48.

In some embodiments, content items that are fetched after off-linepre-rendering is completed, or even after the pre-rendered UI display ismoved to the foreground, can be inserted by the app into the UI displaywith minimal visual impact. In other words, content items may beinserted without requiring complete refreshing or re-rendering of theentire UI display, or requiring only refreshing of only the contentitems being replaced.

On-Line Pre-Rendering Mode

In some embodiments, all pre-rendering in user device 24 is performedusing the off-line mode. In other embodiments, additionally oralternatively to the off-line mode, the user device supports an “on-linepre-render” mode (also referred to as “on-line mode” for brevity) inwhich fetching of content over network 32 for a preloaded app 26 isallowed.

In some embodiments, before the on-line pre-render mode is enabled for agiven app 26, the app is required to declare to PPP agent 48, e.g., viaa suitable API, that it supports the on-line pre-render mode. An app mayuse this API, for example, to declare that it can cope with the serverload associated with on-line pre-rendering.

Any suitable criterion can be used for choosing whether to pre-render agiven UI display of a given preloaded app using the on-line mode orusing the off-line mode. For example, agent 48 may learn the data usagepattern of the app, and use this information to decide whether and whento use the on-line pre-rendering mode. As another example, agent 48 maymonitor the data usage of the app in real-time, and revert to off-linepre-rendering if the amount of data fetched over the network is toolarge, e.g., larger than a threshold. In such a case, agent 48 may alsoavoid further pre-rendering, and/or notify the app developer that theapp is not behaving properly when being pre-rendered.

In some embodiments, when the app declares support for both the off-linepre-render mode and the on-line pre-render mode, PPP agent 48 choosesbetween the two modes considering the lower cost of off-linepre-rendering and the potential for better user experience offered byon-line pre-rendering. The choice may be based, for example, on currentand/or expected network conditions, learned usage patterns of the user,hints from the app regarding expected usage patterns provide to agent 48via an API, user device limitations, a maximal permitted rate ofpreloading/pre-rendering (as detailed below), maximal permitted contentstaleness (as detailed below), and the like. User-device limitations maycomprise, for example, battery state, whether the device is connected toan external power supply, data saving modes, RAM size, Flash size and/ordata budget.

In some embodiments, the app may specify a maximum allowed rate ofpre-rendering for the off-line mode, for the on-line mode, or for both.One motivation for this feature is to ensure that pre-renderingoperations do not overload the app's servers (e.g., portals 28). Forexample, the app may specify a limit of two on-line pre-renderingoperations per day, or one off-line pre-rendering operation and oneon-line pre-rendering operation for every activation of the app by theuser.

In some embodiments, the app may specify a maximal permitted contentstaleness for the off-line mode, for the on-line mode, or for both. Onemotivation for this feature is to ensure that the pre-rendered contentthat the user can see is not older than a given maximal stalenessthreshold. In an example embodiment, the OS enforces the maximalpermitted content staleness by either destroying the preloaded contentor by triggering a refresh of this content (e.g., pre-rendering again)upon reaching the specified maximal staleness.

Content Prefetching and Pre-Rendering Using Parse Chains

In many practical cases, a content item, e.g., a Web page or app feed,comprises one or more additional content items, each of which may linkto one or more yet additional content items, and so on. Fetching of sucha nested content item for an app 26 can be viewed as a “parse chain”:Typically, the app receives the content item, parses it, discovers oneor more additional content items within the parsed content item,requests to fetch the discovered content items, and so on. The app maycontinue this process until no more nested content items are found.

In some embodiments, when executing a parse chain, PPP agent 48 controlsthe fetching of content items for the requesting app 26. The PPP agentmay fetch the content items itself, or it may decide and instruct theapp whether or not to fetch certain content. In particular, in someembodiments agent 48 decides, for each additional content item beingidentified as part of the parse chain, whether to fetch the content itemover the network or not. If the decision is not to fetch a content item,the app's network request is ignored. In such an event, the PPP agentwould typically notify the app that the network request has failed, orthat the network request will not be served. Agent 48 may use variouscriteria for deciding whether an additional content item should befetched or not, and in particular to decide whether to terminate theparse chain entirely.

The control of agent 48 over parse chains is advantageous in varioususe-cases. One example use-case is a preloaded app that runs in thebackground, and whose UI display is being pre-rendered in thebackground. In such embodiments, agent 48 may use the selective fetchingof content items as a “hybrid pre-rendering” mode. In this mode, whenagent 48 permits app 26 to fetch an additional content item that wasidentified by the app as part of the parse chain, the app alsopre-renders the additional content item in the background. When agent 48decides not to fetch an additional content item, this content item willnot be pre-rendered (and will typically be fetched and rendered onlyonce the user accesses the app and the UI display is moved to theforeground). Executing such a prefetch parse chain during pre-renderingis useful, for example, for reducing costs such as integration effort,data usage and battery drain.

In some embodiments, the app is required to declare that it supports thehybrid pre-rendering mode before the mode becomes available. Oncedeclared, agent 48 uses the hybrid pre-rendering mode instead ofnon-selective on-line pre-rendering.

Another use-case relates to prefetching, but not in the context ofpre-rendering. Consider, for example, an app that runs in thebackground, for which agent 48 prefetches content but does not performpre-rendering. This use-case is useful, for example, if pre-rendering isconsidered too costly or is otherwise not desired or not feasible.Pre-rendering may be unavailable, for example, when agent 48 isimplemented as part of an app on an OS that does not allowpre-rendering.

In some embodiments, agent 48 may handle a parse chain by interceptingsome or all of the network calls that occur during pre-rendering orprefetching. Such network calls are treated as optional requests to beprefetched only under certain criteria, e.g., criteria relating toefficiency or safety. Network calls that are not intercepted by agent48, if any, may be allowed to reach the network or may be blocked, asappropriate.

In some embodiments, PPP agent 48 implements a parse chain by providinga suitable API to the app. The app uses this API for sending requests toagent 48 for prefetching content items (instead of the app issuingnetwork calls directly).

Benefits of the disclosed parse-chain handling scheme include, forexample:

-   -   Simplicity of integration: The content items to be prefetched        are discovered through the existing app loading procedure.    -   Ability to prioritize content items to prefetch, e.g., avoiding        downloading of content items that are not deemed worthy of the        associated costs.    -   Ability to use efficient and safe prefetch techniques instead of        the app's default network requests. Such techniques may involve        monitoring the progress of the prefetch and terminating the        downloads if too slow, blacklisting content items that        repeatedly fail to download, redirecting to download content        from separate servers, limiting prefetch resources depending on        recent usage of the app, and/or any other suitable technique.

As can be appreciated, when carrying out the disclosed parse chaintechnique, some of the app's network requests may be ignored by agent48. Therefore, in some embodiments the app is expected to handle ignorednetwork requests correctly, as if the app was run in an off-linepre-render mode, for example by obtaining the requested content fromcache 52.

In some embodiments, if a parse chain was terminated by agent 48, theapp may choose to continue the parse chain by parsing a content itemcached in cache 52, such as images that are linked through a feed json.

In some embodiments, the app provides agent 48 information relating to acontent item, and agent 48 takes this information into account indeciding whether or not to download the content item. Such informationmay indicate, by way of example:

-   -   Whether the content item was discovered from cache and therefore        may be stale.    -   A priority assigned to the content item. For example, content        items discovered from cache may be given low priority.    -   A timestamp indicating the time the content item was last known        to be needed.    -   The expected media type (e.g., text file, image, video).    -   The expected size of the file.

FIG. 3 is a flow chart that schematically illustrates a method forcontent prefetching using a prefetch parse chain, in accordance with anembodiment of the present invention. The method flow is described in thecontext of prefetching (without pre-rendering), by way of example. Inalternative embodiments, pre-rendering can be implemented in a similarmanner as explained above. Also for simplicity, the method flowdescribes a process that terminates the entire parse chain afterprefetching some of the content items. This flow, however, is notmandatory. In alternative embodiments, agent 48 may decide not toprefetch certain content items, but nevertheless proceeds with executionof the parse chain and may subsequently decide to prefetch other contentitems that are discovered later.

The method of FIG. 3 begins with an app 26, e.g., an app that waspreloaded and is currently running in a background mode in user device24, beginning to prefetch content, at a prefetch initiation step 120. Ata request input step 124, PPP agent 48 receives from the app a requestto prefetch one or more content items. At a chain initialization step128, agent 48 initializes a prefetch parse chain for the app.

At a downloading step 132, agent 48 downloads the requested contentitem(s) over network 32 and delivers the content item(s) to app 26 (oralternatively permits the app to download the requested contentitem(s)). The app parses the content item(s), at a parsing step 136. Ata nesting checking step 140, the app checks whether the content item(s)delivered at step 132 link to additional content item(s) to bedownloaded. If so, the app requests agent 48 to prefetch the additionalcontent item(s), at an additional requesting step 144.

Agent 48 evaluates a criterion that decides whether to approve ordecline the app's request for additional content item(s), at aprefetching evaluation step 148. (In some embodiments the criterion canbe evaluated for the initial content item(s) requested by the app, aswell.) If the criterion indicates that the additional content item(s)are approved for prefetching, the method loops back to step 132 above,in which agent 48 and/or app 26 downloads the additional contentitem(s), i.e., executes the next prefetch stage of the parse chain. Ifthe criterion indicates that the additional content item(s) are notapproved for prefetching, agent 48 terminates the parse chain, at atermination step 152. The method also jumps to step 152 upon finding, atstep 140, that no additional content items are to be prefetched in thepreset parse chain.

At any stage of the above flow, the user may access the app. In such acase, agent 48 and/or the app refreshes any missing or stale contentover the network.

Prioritizing of Background and Foreground Ui Tasks

In some embodiments, the OS of user device 24 executes multiple UI tasksfor the various apps 26. Each UI task specifies an action that processesa certain UI display of an app. Some UI tasks may modify the UI displaydirectly, whereas other UI tasks do not directly modify the UI displaybut are prerequisite to such modification or are synced to modificationof the UI display. In the Android OS, for example, UI displays arereferred to as Views or Activities. A UI display is also referred toherein as a “scenario”. Some UI tasks may originate from user actions,whereas other UI tasks may relate to background pre-rendering.

In some cases, the OS runs a single UI thread per app 26. Consider acase in which a user performs actions that affect a UI display of acertain app, while another UI display of the same app is beingpre-rendered in the background. In such a case, the UI tasks derivedfrom the user's actions and the UI tasks relating to pre-rendering allcompete for the resources of the same single UI thread. Unless handledproperly, the pre-rendering UI tasks might cause the app to appearnon-responsive to the user's actions.

Another challenge encountered in the above situation is the need toretain in-order execution of UI tasks associated with a given UIdisplay. Consider, for example, a situation in which one or morepre-rendering UI tasks for a given UI display are pending for execution,and then a user performs an action that modifies the same UI display. Insuch a case, even though the user's action is in the foreground and aremore latency-sensitive than the background pre-rendering tasks, it wouldbe incorrect to execute the user's UI tasks before the pendingpre-rendering tasks.

Typically, the in-order requirement holds for UI tasks associated withthe same UI display, but UI tasks of different UI displays are allowedto be handled out-of-order.

In some disclosed embodiments, PPP agent 48 in user device 24 overcomessuch challenges by correctly prioritizing and scheduling the various UItasks. In some embodiments, PPP agent 48 assigns to each UI task apriority selected from at least a Foreground (FG) priority and aBackground (BG) priority. In addition, PPP agent 48 associates each UItask with the UI display (“scenario”) being processed (e.g., modified orprepared, for example) by this UI task. PPP agent 48 then schedules theUI tasks for execution in accordance with a schedule that (i) givesprecedence to the UI tasks having the FG priority over the UI taskshaving the BG priority, and (ii) for any UI display, retains in-orderexecution of the UI tasks associated with the UI display. Typically, inspecifying the schedule, the PPP agent does not enforce any constraintsas to the order of execution of UI tasks associated with different UIdisplays (other than, of course, giving precedence to FG tasks over BGtasks). The UI tasks are then executed in accordance with the schedule.

In some embodiments, in order to retain in-order execution of the UItasks of a given UI display, PPP agent 48 applies a “promotion”mechanism that promotes selected UI tasks from the BG priority to the FGpriority. In response to creation of a new UI task having the FGpriority (e.g., derived from a user action), agent 48 identifies all UItasks that (i) are associated with the same UI display as the new UItask and (ii) have the BG priority, and promotes the identified UI tasksto the FG priority. Agent 48 then schedules the promoted UI tasks to beexecuted before the new UI task. Agent 48 also retains the originalorder of execution among the promoted UI tasks.

In some embodiments, a UI task may be associated with multiple UIdisplays, in which case agent 48 promotes the UI task if a newFG-priority UI task is added in any of these multiple UI displays.

In some embodiments, PPP agent 48 represents the various UI tasks asmessages. In the description that follows, the terms “UI task” and“message” are used interchangeably. A single user action, or a single UIchange by the app or the user device in general, may be translated intoseveral smaller UI tasks, e.g., drawing a portion of the screen,invoking an app callback or creating a new view or screen. Each such UItask is represented by a message. Agent 48 queues the messages in asuitable queue structure, and schedules the queued messages forexecution by the UI thread.

Any suitable queue structure can be used for queuing the messages, e.g.,a priority queue, a set of queues with each queue holding the messagesof a respective priority, a multi-threaded UI environment with eachthread assigned to handle messages of a respective priority, or even amulti-process structure in which different processes handle differentpriorities.

In some embodiments, agent 48 starts a predefined time-out (denoted T1)following the execution of a foreground message, and ensures thatbackground messages are only handled if no foreground messages have beenhandled for T1 seconds.

In some embodiments, agent 48 may schedule messages to be handled at aspecified time in the future, and halt the handling of backgroundmessages if a foreground message is scheduled to be handled in the nearfuture. The time interval considered “near future” in this context maybe constant (denoted T2), or may be based on an estimation of theexpected running time of the background message in question. Forexample, if a foreground message is scheduled to start being handled inthree seconds, then a background message whose handling is expected totake two seconds will be allowed to proceed, while a background messagewhose handling expected to take four seconds will not be allowed toproceed at this time.

In some embodiments, agent 48 may delete a background message if itsassociated UI display becomes no longer relevant. For example, in theAndroid OS, when an Activity is destroyed, if a UI display based on thatActivity exists, agent 48 deletes all messages associated with this UIdisplay.

In various embodiments, UI tasks may be assigned priorities in variousways. For example, the app developer may specify the priority of each UItask or message to be queued. As another example, the app developer mayspecify the priority of a certain UI display that needs to be processed.In this case, messages associated with this display will receive thespecified priority. In some embodiments the priority may be assignedautomatically by agent 48. For example, tasks that are independent ofimmediate needs of the user may be assigned BG priority.

In some embodiments, specific UI components may be modified to takeadvantage of the priority system, and some or all of their tasks areassigned to BG priority. Consider, for example, a UI component thatholds multiple tabs that the user may browse, such as Android ViewPager.Such a component may load multiple tabs together, assign FG priorityonly to the visible tab, and BG priority to adjacent tabs. Thisassignment helps provide the fastest response to the user while stillloading adjacent tabs ahead of time.

In some embodiments, agent 48 may automatically assign BG priority toviews that are drawn but not currently visible, for example views thatare “below-the-fold” and require scrolling to become visible.

In some embodiments, agent 48 creates UI displays (e.g., views orAndroid Activities) predictively before the user requires them, and setsthe priorities of their UI tasks to BG priority.

In some embodiments, agent 48 assigns more than two priorities. Forexample, non-visible views (i.e., views that are “below-the-fold”) of aforeground activity may have higher priority than views of otherpre-rendered activities, but lower priority than the view which isvisible. The promotion among multiple priorities may be defined suchthat when a message with a specific priority P and UI display S is sent,all messages of UI display S with priorities that are lower that P arepromoted to priority P.

In various embodiments, UI tasks (messages) may be associated with UIdisplays (“scenarios”) in various ways. In some embodiments, PPP agent48 associates UI tasks with UI displays automatically. For example, inthe Android OS, example associations may comprise:

-   -   For an Activity's main Handler, the Handler is marked with the        Activity as the associated UI display, which the Handler then        assigns to all messages passing through it.    -   For views that are attached to an Activity, the Activity may be        set as the UI display by default for messages related to those        views.    -   Messages that pass the Activity as a parameter, set the        message's UI display to be the Activity. Note that the Android        OS regularly sends the Activity as a parameter to some of the        messages related to the Activity.

In some embodiments, the app developer may choose which UI display isassociated per message. In such embodiments, and if agent 48 alsoautomatically associates messages with UI displays, then the developer'schoice may override the choice of agent 48.

In some embodiments, agent 48 may modify pre-rendering related UI tasksto take into account that the results are not immediately visible to theuser. For example, agent 48 may reduce the frame-rate for background UItasks, or may avoid running animations, jumping directly to the endresult of the animation. Such manipulation is done to reduce the loadintroduced by background tasks, while also completing the backgroundtasks faster. In some embodiments, agent 48 may split UI tasks intosmaller portions, so that handling each message may be quick, allowinggreater control over message scheduling.

In some embodiments, if a FG message is created while a BG message isbeing handled, agent 48 allows the running BG message to complete beforehandling the FG message. In other embodiments, agent 48 pauses handlingof the BG message, saves the state of the paused message, then handlesthe FG message, and then resumes handling of the paused BG message fromthe saved state. In yet other embodiments, agent 48 stops handling theBG message and reverses its effects, then handles the FG message, andthen retries handling the BG message from the beginning. To this end,agent 48 may use a transaction system for messages, so that the effectsof a message will not persist unless the message is handled completelyand committed.

FIG. 4 is a flow chart that schematically illustrates a method forhandling background and foreground UI tasks using a single UI thread, inaccordance with an embodiment of the present invention. The methodbegins with PPP agent 48 receiving a new UI task, at a task input step160. Agent 48 represents the new UI task as a message, at a messagerepresentation step 164, and associates the message with a UI display (a“scenario”, e.g., an Android Activity), at a scenario assignment step168.

At a FG/BG checking step 172, agent 48 checks whether the messagerelates to a user action or to a pre-rendering operation. If the messagerelates to pre-rendering, agent 48 assigns the message a BG priority andadds the message to the queue structure, at a BG prioritization step176. Agent 48 schedules the message for execution, at a scheduling step180.

If, on the other hand, the message was derived from a user action, agent48 assigns the message a FG priority and adds the message to the queuestructure, at a FG prioritization step 184. Agent 48 then checks whetherany of the queued messages are both (i) assigned the BG priority and(ii) associated with the same UI display (“scenario”) as the new FGmessage. If so, agent 48 promotes these messages to the FG priority, ata promotion step 192. With or without promotion, agent 48 proceeds toschedule the message at scheduling step 180.

It will be appreciated that the embodiments described above are cited byway of example, and that the present invention is not limited to whathas been particularly shown and described hereinabove. Rather, the scopeof the present invention includes both combinations and sub-combinationsof the various features described hereinabove, as well as variations andmodifications thereof which would occur to persons skilled in the artupon reading the foregoing description and which are not disclosed inthe prior art. Documents incorporated by reference in the present patentapplication are to be considered an integral part of the applicationexcept that to the extent any terms are defined in these incorporateddocuments in a manner that conflicts with the definitions madeexplicitly or implicitly in the present specification, only thedefinitions in the present specification should be considered.

1. A method, comprising: in a user device, which is configured toexecute User Interface (UI) tasks that process one or more UI displayspresented to a user, assigning to each UI task among the UI tasks (i) apriority selected from at least a Foreground (FG) priority and aBackground (BG) priority, and (ii) an association with a UI displaybeing processed by the UI task; scheduling the UI tasks for execution inaccordance with a schedule that (i) gives precedence to the UI taskshaving the FG priority over the UI tasks having the BG priority, and(ii) for any UI display, retains in-order execution of the UI tasksassociated with the UI display; and executing the UI tasks in accordancewith the schedule.
 2. The method according to claim 1, wherein one ormore of the UI tasks having the BG priority comprise pre-renderingtasks.
 3. The method according to claim 1, wherein, at a given time, theUI tasks comprise both (i) one or more UI tasks having the BG priority,and (ii) one or more UI tasks having the FG priority that relate to useractions.
 4. The method according to claim 1, wherein executing the UItasks is performed by a single UI thread per user application.
 5. Themethod according to claim 1, wherein assigning the priority comprises,in response to addition of a new UI task having the FG priority,identifying one or more UI tasks that (i) are associated with a same UIdisplay as the new UI task and (ii) have the BG priority, and promotingthe identified UI tasks to the FG priority.
 6. The method according toclaim 5, wherein scheduling the UI tasks comprises scheduling thepromoted UI tasks to be executed before the new UI task.
 7. The methodaccording to claim 5, wherein scheduling the UI tasks comprisesretaining an original order of execution among the promoted UI tasks. 8.The method according to claim 1, wherein scheduling the UI taskscomprises permitting out-of-order execution of UI tasks associated withdifferent UI displays.
 9. A user device, comprising: an interface forcommunicating over a network; and a processor, configured to: assign, toeach User Interface (UI) task from among multiple UI tasks that processone or more UI displays presented to a user, (i) a priority selectedfrom at least a Foreground (FG) priority and a Background (BG) priority,and (ii) an association with a UI display being processed by the UItask; schedule the UI tasks for execution in accordance with a schedulethat (i) gives precedence to the UI tasks having the FG priority overthe UI tasks having the BG priority, and (ii) for any UI display,retains in-order execution of the UI tasks associated with the UIdisplay; and execute the UI tasks in accordance with the schedule. 10.The user device according to claim 9, wherein one or more of the UItasks having the BG priority comprise pre-rendering tasks.
 11. The userdevice according to claim 9, wherein, at a given time, the UI taskscomprise both (i) one or more UI tasks having the BG priority, and (ii)one or more UI tasks having the FG priority that relate to user actions.12. The user device according to claim 9, wherein the processor isconfigured to execute the UI tasks by a single UI thread per userapplication.
 13. The user device according to claim 9, wherein, inresponse to addition of a new UI task having the FG priority, theprocessor is configured to identify one or more UI tasks that (i) areassociated with a same UI display as the new UI task and (ii) have theBG priority, and to promote the identified UI tasks to the FG priority.14. The user device according to claim 13, wherein the processor isconfigured to schedule the promoted UI tasks to be executed before thenew UI task.
 15. The user device according to claim 13, wherein theprocessor is configured to retain an original order of execution amongthe promoted UI tasks.
 16. The user device according to claim 9, whereinthe processor is configured to permit out-of-order execution of UI tasksassociated with different UI displays.